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[57] ABSTRACT 

A system for posting and downloading messages and files 
from a bulletin board system is described. The system allows 
a user to retrieve a message from a bulletin board system and 
then selectively download files which are represented within 
the message as objects, which may be visually presented to 
a user as icons. 
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METHOD OF UPLOADING A MESSAGE 
CONTAINING A FILE REFERENCE TO A 
SERVER AND DOWNLOADING A FILE 
FROM THE SERVER USING THE FILE 
REFERENCE 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to bulletin board services on 
computer networks and, more specifically, this invention 
relates to on-line bulletin board services having object- 
oriented file handling features. 

2. Description of the Related Technology 

Bulletin board services, or BBSS, are systems that allow 
users to post and download public messages. These bulletin 
board services normally have many different file libraries 
and discussion groups so that clients can communicate with 
one another through an on-line connection. In addition, 
bulletin board services can be provided as part of large 
on-line networks such as the Microsoft® Network (MSN). 

For example, CompuServe, America On-line, Prodigy 
and many other large network systems have bulletin board 
services as integrated features. Users of these network 
systems can post messages to various groups within the 
bulletin board service so that many different clients can read 
their message. For example, a client may post a message to 
the bulletin board service requesting information on a par- 
ticular software program. Other users of the network service 
will read this message and can respond by posting messages 
of their own which include an answer. All of these messages 
are publicly available and can usually be read by any user. 

Since a large number of users can post thousands of 
messages, the bulletin board service is divided into separate 
groups based on different subjects. For example, one group 
may contain discussions of computer software, while 
another group may be for discussions of classical music. The 
bulletin board service that is provided within the Internet 
contains thousands of various discussion groups on a wide 
range of issues. 

Aside from posting messages to a bulletin board service, 
many users also exchange computer programs and data files 
by posting them to the publicly available BBS along with 
their messages. In this manner, the posted software is 
available to potentially millions of other clients who can 
download and retrieve the posted data file. Many different 
types of shareware files are distributed this way through a 
BBS. 

Unfortunately, many bulletin board systems do not have 
convenient file handling capabilities. Within many systems, 
a client wishing to post a file must send a message that 
includes directions for finding the file within the BBS and 
then separately upload the data file. One example of a 
direction within this type of message might be to look for the 
file within a particular download directory in the online 
network. This method of sending and retrieving files is very 
inconvenient because it requires the client to first read the 
posted message and then switch programs to search a file 
download directory to find the desired program. 

Other bulletin board systems embed the shareware file 
within the message itself. For example, a data file can be 
inserted within the body of the BBS message after being 
encoded with a program such as UUENCODE. The encod- 
ing software converts the data file into characters that can be 
inserted into the body of the message. The encoded data file 
is transmitted as if it was text within the message. If a user 



3,846 

2 

wishes to download the program, the entire message, con- 
taining the encoded file is sent to the client's computer 
where the program can be decoded from the message and 
saved to the client's hard disk. Unfortunately, this system 

5 forces the user to transfer an enormous file along with any 
message. There is no provision for first reading the message 
and then determining to download the file or not. In some 
cases, these large messages may take up to an hour to 
download to the client computer. 

10 Other types of computer programs, such as electronic 
mail (Email) systems allow users to embed objects within 
the mail messages. One such system is the Microsoft® Mail 
program. However, Email programs such as Microsoft® 
Mail do not allow files to be selectived downloaded through 

is a publicly accessible location on a computer network. 
Furthermore, the Internet community has submitted a pro- 
posal for a Multipurpose Internet Mail Extension (MIME, 
RFC 1521) to allow direct embedding of various data typed 
files in messages. However, such a system requires the raw 

20 data to be encoded before uploading to the network and, in 
addition, the size of the message is of the same order as the 
data being embedded. For all of the above reasons, a need 
exists for a bulletin board system which has convenient file 
handling capabilities. 

25 SUMMARY OF THE INVENTION 

One aspect of the present invention is a method for storing 
and retrieving a message to a publicly accessible location on 
a computer network, including: creating a message includ- 

30 ing an object representative of a file; uploading the message 
to a publicly accessible location on the network; and down- 
loading the message from the publicly accessible location to 
a client computer. 

Another aspect of the present invention is a computer 

35 network that includes a plurality of message groups, each 
group storing a plurality of messages; a first client computer 
connected to the network and including a program capable 
of including objects indicative of files in messages and 
transferring messages to the network; and a second client 

40 computer connected to the network and including a program 
capable of transferring messages from the network and 
selectively transferring files by selecting the included 
objects. 

Still another aspect of the present invention is a process 

45 for retrieving a message on a computer network including: 
accessing a publicly available message group; displaying a 
message accessed from said message group on a client 
computer; and selecting an object representative of a file in 
said message wherein said selection causes the file to be 

50 downloaded to the client computer. 

An additional embodiment of the present invention is a 
method for storing and retrieving a message to a publicly 
accessible location on a computer network, including: cre- 
ating a message including an object representative of a file; 

55 uploading the message and file to a publicly accessible 
location on the network; storing the file and message in 
separate storage locations on said network; and downloading 
the message from the publicly accessible location to a client 
computer independently of the file. 

60 Yet another aspect of the present invention is a method of 
transferring a data file from a network, comprising the steps 
of: retrieving a message including an object from the net- 
work; displaying the message and an icon representative of 
the object; selecting the icon; displaying object information 

65 relating to the file in response to the selecting; and trans- 
ferring the file from the network in response to the displayed 
object information. 
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Still another aspect of the present invention is, in a of substorages (subdirectories) and any number of streams 

messaging system, a method of saving a message referring (files). Furthermore, each storage has its own access rights, 

to a file of non-text data type to a network, comprising the The IStorage interface describes the capabilities of a storage 

steps of: providing a file, at least a portion of the file object, such as enumerate elements (dir), move, copy, 

comprising a non-text data type; inserting a link to the file 5 rename, create, and destroy. A storage object itself cannot 

in a message; sending the message and the file to the store application-defined data except that it impficitly stores 

network; and saving the message in a publicly accessible names of the elements (storages and streams) contained 

location on the network. within it. 

Storage and stream objects are sharable between pro- 

BRIEF DESCRIPTION OF THE DRAWINGS 10 cesses. This enables objects running in-process or out-of- 

process to have equal incremental access to their on-disk 
FIG. 1 is an block diagram of the bulletin board system st0 rage. Because OLE is loaded into each process separately, 
and illustrates clients, vendors and a host data center. j t must use some operating-system-supported shared 
FIG. 2 is a flow diagram illustrating an overview of the memory mechanisms to communicate between processes 
bulletin board system. about opened elements and their access modes. In that way, 
FIG. 3 is a flow diagram illustrating the create message to 15 ? tora p itse lf becomes another mechanism-an interface- 
be posted process of FIG. 2. based mechanism— for shared memory. In fact, OLE uses a 
. . _ . shared stream implemented on top of shared memory to pass 
FIG. 4 is a flow diagram of the post message process of parameters ^ return values between proxy aml stub objects 

FIG. 2. when generating remote procedure calls. 

FIG. 5 is a block diagram showing the movement of data 20 Application design with structured storage 

structures in the post message process of FIGS. 2 and 4. OLE Structured Storage makes it much easier to design 

FIG. 6 is a flow diagram illustrating the read message and applications that by their nature produce structured infor- 

download files process of FIG. 2. mation. For example, consider a "diary" program that allows 

FIG. 7 is a block diagram showing the movement of data a ^ t0 make entries for da Y of montQ of an y vear - 

structures in the read message and download files process of 25 E^nes are made ia the fonn of 111 ob J ect that ll ? elf mana g es 

FIGS 2 and 6 some information. Users wanting to write text into the diary 

would store a text object; if they wanted to save a scan of a 

DETAILED DESCRIPTION OF THE newspaper clip they would use a bitmap object, and so forth. 

PREFERRED EMBODIMENT Without a powerful means to structure information of this 

n c . , . , u ■ i -i 30 kind, the diary application might be forced to manage a very 

Reference is now made to the drawings wherein like , . . LJ ■ • * 

i r • ii *l l . n • *u large file structure with an overabundance of seek pointers, 

numerals refer to like parts throughout. For convenience, the f . . , - . . „ « . \, 

r n • j • -ii u j ■ *. tu c li * In this kind of situation, even a small change m the size 

following description will be organized into the following „ » . r , b lL . . t 

. -i nL . . T . . . , r . j j- of a text obiect or an addition of a day or month might 

principle sections: Object Linking and Embedding . . i , , A . A J c , n . 4 f~ 

.Background, Advantages of the BBS, Bulletin Board Sys- ******* changes throughout the rest of the file to update 

5; . i i . i --v • o * r\ *• 35 seek onsets. Not only is this tedious to manage, but the 

tem Overview, Architectural Overview, System Operation .... .* . . * c 

and Conclusion application also would have to spend enormous amounts oi 

time moving information around in the file to make space for 

I. OBJECT LINKING AND EMBEDDING data that expands. Or the application can move the newly 

BACKGROUND enlarged data to the end of the file and patch a few seek 

. , t t 40 offsets, but that introduces the whole problem of managing 

One aspect of the present mvention is the use of embed- ^ ffee created k tfae middle of ^ file to minimize 

ded Object Linking and Embeddmg (OLE) objects within a wasle ^ weU as overall file size 

BBS message. The following discussion provides back- The 51ems are com pounded further with objects 

ground on the OLE architecture. While 0I£, available by ^ of readin and theif Qwn ^1^^ to 

Ucense from Microsoft Corporation, is the presently pre- 45 stQra In ^ exa le ^ tfae dia lication would 

ferred object architecture, it will be understood that other fef to • each objc ct m h{ ^ 

architectures could be used such as, for example, Open Doc and ^ Qn _ its Qwn iece of the fifc tQ ^ whatcver the 

available from the Open Doc Consortium. object wants. The only practical way to do this with a single, 

The OLE Structured Storage model defines two types of fl at fij e ^ f or me diary application to ask each object for a 

storage elements: storage objects and stream objects. The 50 memory copy of what the object would like to store, and 

operating or file system itself generally implements these men the diary wou id write that information into a place in its 

objects; applications rarely, if ever, need to implement them. own m ^ W hile this works reasonably well for small 

These objects, like all others in OLE, implement interfaces: amounts of data, consider an object that wants to store a 

IStream for stream objects, IStorage for storage objects. 10-MB bitmap scan of a true-color photograph — 

A stream object is the conceptual equivalent of a single 55 exchanging that much data through memory is horribly 

disk file. Streams are the basic file system component in inefficient. Furthermore, if the user wants to later make 

which data lives with each stream having access rights and changes to that bitmap, the diary would have to load the 

a single seek pointer. Through its IStream interface, a stream bitmap in its entirety from its file and pass it back to the 

can be told to read, write, seek, and perform a few other object. 

operations on its underlying data. Streams are named by eo The OLE Structured Storage technology solves these 

using a text string and can contain any internal structure problems through the extra level of indirection of a file 

because they are simply a flat stream of bytes. In addition, system within a file. With OLE, the diary application can 

the functions in the IStream interface map nearly one-to-one create a structured hierarchy where the root file itself has 

with standard file-handle-based functions such as those in substorages for each year in the diary. Each year substorage 

the ANSI C/C++ run-time library. 65 has a substorage for each month, and so on. 

A storage object is the conceptual equivalent of a direc- This structure solves the problem of expanding informa- 

tory. Each storage, like a directory, can contain any number tion in one of the objects: The object itself expands the 
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streams in its control, and the implementation of storage 
determines where to store all the information in the stream. 
The diary application doesn't have to perform any specific 
routines. Furthermore, the implementation automatically 
manages unused space in the entire file, again relieving the 
diary application of a great burden. 

In this sort of storage scheme, the objects that manage the 
content in the diary always have direct incremental access to 
their piece of storage. That is, when the object needs to store 
its data, it writes it directly into the diary file without having 
to involve the diary application itself. The object can, if it 
wants to, write incremental changes to that storage, thus 
leading to much better performance. 

If the user wants to make changes to that information later 
on, the object can then incrementally read as little informa- 
tion as necessary instead of requiring the diary to read all the 
information into memory first. Incremental access, a feature 
that has traditionally been very hard to implement in 
applications, is now the default mode of operation. 
Direct access versus transaction access 

Storage and stream elements support two fundamentally 
different modes of access; direct mode and transacted mode. 
Changes made while in direct mode are immediately and 
permanently made to the affected storage object. In trans- 
acted mode, changes are buffered so they can be saved 
("committed") or reverted when modifications are complete. 

If an outermost-level IStorage is used in transacted mode, 
a robust two-phase commit operation is used to publish 
those changes to the underlying file on the file system. That 
is, great pains are taken not to lose the user's data should an 
untimely crash occur. 
Persistent objects 

Because OLE allows an object to read and write itself to 
storage, there must be a way through which the client tells 
objects to do so. The way is, of course, additional interfaces 
that form a storage contract between the client and objects. 
When a client wants to tell an object to deal with storage, it 
queries the object for one of three interfaces, as suits the 
context: 

IPersistStorage: Object can read and write its persistent 
state to a storage object. The client provides the object 
with an IStorage pointer through this interface. This is 
the only IPersist* interface that includes semantics for 
incremental access, 

IPersistStream/IPersistStreamlnit: Object can read and 
write its persistent state to a stream object. The client 
provides the object with an IStream pointer through this 
interface. 

IPersistFile: Object can read and write its persistent state 
to a file on the underlying system directly. This inter- 
face does not involve IStorage or IStream unless the 
underlying file is itself accessed through these 
interfaces, but the IPersistFile itself has no semantics 
relating to such structures. The client simply provides 
the object with a filename and orders to save or load; 
the object does whatever is necessary to fulfill the 
request. 

As will be discussed in the following sections, OLE 
technology is used as a mechanism to provide some of the 
advantages of the present invention. 

II. ADVANTAGES OF THE BBS 

The bulletin board system of the present invention allows 
a user to conveniently upload and download files to a 
publicly accessible location on a computer network. As used 
herein, a publicly accessible location may be implemented 
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in a bulletin board system wherein individuals can post 
messages to the networked public. This can be distinguished 
from, for example, an electronic mail system wherein indi- 
vidual messages are sent from one person to another 

5 individual, but are not posted for review and comment by the 
networked public. 

In the present invention, OLE technology is used to 
include objects representing files within the body of a BBS 
message. Specifically, a user can insert an icon representa- 

10 tive of a file within the body of a message to be posted while 
the file remains in a separate location on the client computer. 
Because the embedded object retains a link to the associated 
file, when the message is posted to the bulletin board system 
the file is automatically transmitted along with the message. 

IS However, this system does not suffer from the disadvantages 
of prior bulletin board systems because the actual file is not 
embedded within the body of BBS message. 
Posting a Message 

Several advantages exist in the present invention for 

20 posting a message to a bulletin board service. In practice, by 
the use of OLE technology, the user can "drag and drop" a 
file into the body of a message. Once the user has placed an 
icon representing the file to be posted within the body of the 
BBS message, the system of the present invention efficiently 

25 handles sending that file to the publicly accessible BBS 
server for storage and retrieval by other users. The user is not 
required to encode or decode files as within other BBS 
systems. In addition, the actual file itself is not included 
within the message, only an embedded object which retains 

30 a link to the file. This provides a tremendous advantage 
when retrieving the file as will be discussed below. 

In addition, the system of the present invention can 
compress and decompress the posted file without the user 
having to run external programs such as PKZIP® available 

35 from PKWARE Incorporated. The automatic file compres- 
sion features of the present invention dramatically increase 
the speed of uploading files from a client computer to the 
BBS system. 
Retrieving a Message 

40 The system of the present invention is very convenient for 
browsing through many messages to find a data file having 
a particular data type or types, e.g., text document, image, 
animation, audio, etc., to be downloaded. Since the actual 
files remain resident on the BBS system, even after a 

45 message is sent to a client computer, the speed of this system 
is much greater than those seen in the prior art. For example, 
a BBS message which includes relatively small embedded 
objects representing a data file could be retrieved by a user 
very quickly since the potentially very large data file remains 

50 on the server. 

However, a BBS message such as those found in the prior 
art which includes the actual file stored within the body of 
the message might take up to an hour to be retrieved by the 
user. As can be imagined, the user would not be able to read 

55 the message until the file download was completed. The user 
of prior art systems is forced to wait for all embedded data 
files to be retrieved before being able to read the BBS 
message. Thus, prior art systems are very slow and difficult 
to use. 

60 In contrast, when a user of the present invention retrieves 
a message, all that is sent is the text of the message and the 
small embedded objects which retain a link to their associ- 
ated data file. A user can read the entire message and then 
select one or more files represented by the embedded objects 

65 to be specifically downloaded. The capability of having 
multiple files embedded within the body of the message is 
also unique, since most prior bulletin board systems only 
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allowed for a single file to be embedded within the message 
body. For all of the reasons mentioned above the bulletin 
board system of the present invention provides many advan- 
tages over prior art systems. 

5 

III. BULLETIN BOARD SYSTEM OVERVIEW 

The Bulletin Board System of the present invention 
provides users with a way to ask and answer questions, 
create and read answers to questions, find information, and iq 
hold non-realtime discussions with other BBS users inter- 
ested and/or knowledgeable in the same topics. Bulletin 
boards are usually organized by topic so that users with 
similar interests can interact with one another. Individual 
bulletin boards are also called groups or newsgroups. Sub- ^ 
topics of a newsgroup are called threads. 

A thread is a collection of messages organized chrono- 
logically and hierarchically to reflect the flow of a discussion 
between users. A message is an individual posting to the 
bulletin board. 20 

In" the presently preferred embodiment of the present" 
invention, the bulletin board system is a component of the 
Microsoft® Network. However, it will be understood that 
other networks such as, for example, the Internet, may be 
utitlized in conjunction with the present invention. The 25 
bulletin board service is accessible on a client computer by 
implementing features extending the functionality of the 
Microsoft Windows 95® Explorer, using the Windows 95 
tree navigation application program interface (API) in con- 
junction with the Microsoft On-line System (MOS) 30 
transport, and using a High Performance Message System 
(HPMS) backend. 

The MOS bulletin board service, which executes on a 
BBS server located in a host data center, preferably includes 
a large in-memory cache to increase message throughput. 35 
The BBS server preferably runs under the Windows NT 
operating system available from Microsoft Corporation. 
Preferably, the BBS server is a Pentium-class (or better) 
microcomputer with at least 128 MB of random-access 
memory (RAM) and at least 4 Gigabytes of hard disk space. 40 

The bulletin board system supports at least two types of 
BBS folders: public and private. Public folders are used for 
generally available newsgroup folders, such as those that are 
available to all users on the on-line network. Private folders 
are used for communication restricted in some way, such as 45 
folders created for personal correspondence among families 
and friends. 

IV. ARCHITECTURAL OVERVIEW 

50 

FIG. 1 illustrates a high level diagram of the general 
architecture of the bulletin board service in accordance with 
the present invention. A host data center 10, which houses a 
network of many computer systems and servers, is shown 
having a plurality of gateways 12. These gateways provide 55 
a linkage between the host data center 10 and a set of clients 
14#, 14b and vendors 16a, 16b. The clients and vendors 
communicate through a wide area network (WAN) 18 to the 
gateways 12 within the host data center 10, The WAN lines 
are provided by one or more telecommunications companies 60 
and allow clients over a wide geographic area to access the 
host data center 10. The WAN preferably includes both X.25 
lines and Integrated Service Digital Network (ISDN) lines. 

The gateways 12 and other computers within the host data 
center 10 communicate with one another through a series of 65 
high speed network cables 22. These network cables can 
include twisted pair, coaxial cable or fiber optic products. 
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However, the most preferable network cables are 100 Mega- 
bit per second fiber optic communication lines. 

As illustrated in FIG. 1, the gateways 12 communicate 
with a file transfer manager (FTM) server 24 through the 
network cables 22. The FTM server 24 is responsible for 
handling file transfers between other servers within the host 
data center 10 and the vendor and client computers that are 
linked through the gateways. For example, a bulletin board 
server 26 is shown as linked to the FTM server 24 and 
gateway 12a through the network 22. The network 22 can 
also communicate between a billing server 28, administra- 
tion servers 30 and another gateway 32 which provides 
access to a second host data center 34. 

The client side of the BBS system includes software for 
reading and posting messages to and from a publicly acces- 
sible location on a computer network. The on-line services 
offered to the clients 14 are preferably in the form of client 
server application programs or "service applications". Each 
service application includes a server portion that runs on one 
or more servers within the host data center 10 and at least 
one corresponding client portion (also referred to as a "client 
application") that runs on a microcomputer of the client 14. 
In the presently preferred embodiment, the client applica- 
tions for the bulletin board system are in the form of 
Microsoft Windows 95 executables, and the server portions 
are implemented as dynamic link libraries (DLLs) running 
under the Microsoft® Windows NT operating system. FIG. 
2 is a flow diagram illustrating the process of starting a BBS 
client and reading and posting messages. 

VI. SYSTEM OPERATION 

As illustrated in FIG. 2, the BBS client begins operation 
on the client computer 14 at a start state 52. The BBS client 
software is preferably written in C++ and runs under the 
Microsoft Windows 3.1 or Microsoft Windows 95 operating 
system. It should be noted however that similar software can 
be programmed in different languages and designed to run 
under various operating systems and still be within the 
purview of the present invention. 

When the BBS client starts at the state 52 a window opens 
on the client computer and lists the various messages that are 
available to be read. While in this browsing mode the user 
can scroll through many messages and select the one which 
is most appealing. Each message normally includes a subject 
line which indicates the subject matter of the posted mes- 
sage. Once the user has started the BBS client at state 52 a 
decision is then made at a decision state 54 whether or not 
to read a particular message. 

If a choice is made to read a particular message at decision 
state 54 then that message is selected at a state 56. As is well 
known in the art, a message can be selected by highlighting 
it with a mouse and pressing the enter key, or double clicking 
on the selected message with a mouse button. While these 
commands are primarily used with the Windows Operating 
System, other methods of selecting messages might also be 
available. Once a particular message has been selected to be 
read at state 56, a read window is opened at a state 58. 

In this system, the read window contains two separate 
areas known as the header and body sections of the message. 
The header section includes information such as the name of 
the person posting the message, the subject of the message 
and the date that the message was posted. 

The body section of the message contains the text of the 
message itself along with any included object such as a 
picture, a sound or a video. This differs from many other 
BBS systems because objects can be embedded directly 
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within the body section of the message. This will be Once the user has identified the file at state 112 a file 

explained more fully below in reference to FIG. 5. object is created at state 114. Within the present invention 

Once the read window is opened at state 58 the user reads the preferable object is known as MOSAF (Microsoft 

the message and downloads any desired files at a process 59 On-Line System Attach File). This object was designed to 

and then closes the read window at a state 60. The process 5 hold properties of the attached file which are later used for 

of reading messages and downloading files is discussed in identifying the file within the message. The MOSAF object 

detail in reference to FIG. 6. Once the read window is is derived from the Microsoft Foundation Class (MFC) and 

closed, this message is normally marked within the BBS nas properties shown in Table 1. A "class" as discussed 

system as being read. The user can then choose to only view herein ^ a definition of a data type that specifies the 

messages which have not been read while they are browsing 1Q represerjtation of objects of the class md me &t of opera . 

the available messages. Once the read window is closed at dons ^ ^ be Ued tQ lhe objects ^ objecl of a dass 

state 60 an inquiry is made at a decision state 62 whether to fe a ioQ of e Qr me Jhe notkm of a « class „ ^ 

read another message. If the decision is made to read another . j t , . °, 1 -n j ■ *u u - * • . a ~ 
4U *u - A r j- j be understood by those skilled in the obiect-onented pro- 
message, then the process 50 of reading and posting mes- . , J . , . . . •> A . <? m • 
sages loops back to select a message at state 56. If a decision S^mmmg . technology and, in particular, by those familiar 
is made to not read another message at decision state 62 then 1S ™ lth * e C++ programming language. Classes may be 
the process 50 inquires whether to post a message at a morc ^ comprehended by reference to The Annotated 
decision state 64. C++ Reference Manual, Ellis, Margaret and Stroustrup, 

If a decision is made to post a new message at decision B J ame > Addison- Wesley Publishing Co., 1990. 
state 64, then a posting window is opened at a state 66 which 

resembles the read window discussed above. The posting 20 _ TABLE I 
window includes both header and body sections of the 
message that can be filled in by the user. Once the posting 

window is opened at state 66 a message is created for properties definition 
posting at process 68 when the user fills in the header and 



PROPERTIES OF MOSAF OBJECT 



body sections Of the message 25 Compression Method Compression method used to compress file: 

After the message is created at process 68, it is posted at Versioi Number ^ 
process 70 so that it can be available for use on a publicly state state of object: 

accessible location on a computer network. The process of unsent — created but not yet sent 

posting messages from a client computer to the network is remote — file has not been downloaded 

described more fully by reference to FIGS. 3 and 5. After the 30 c . ^CAX - file has been downloaded 

J J File Size Size of compressed file to be sent or 

message has been posted at process 70, an inquiry is made downloaded 

whether the user is done at a decision state 72. If the user is Name size size of name of file (not including a null 

not done, the process 50 loops back to inquire whether to terminator) 

read more messages at decision state 54. However, if the Attached File Name of attached file 



user is done at decision state 72, then the process 50 ends at 35 

an end state 74. The MOSAF object is an inprocess object server (DLL) 

Creating a Message and supports the I Unknown, IClassFactory, IPersistStorage, 

The overall process of reading and posting messages has IOleObject, IDataObject and IViewObject interfaces as 

been described above in reference to FIG. 2. FIG. 3 details required by OLE. A custom interface, IMosAttachedFile, is 

the process 68 of creating messages to be posted after a 40 defined for manipulating the file represented by the MOSAF 

posting window has been opened. Referring now to FIG. 3, object. This object exposes the following methods: 

the process of creating a message to be posted 68 begins at STDMETHOD(SetFile) (THIS_LPCSTR) PURE; 

a start state 100 and then moves to state 102 where header _ . . , . .... . . , ■, • , 

information is placed in the header section of the message. u 7** method ™l£ T £ Ta 

As discussed above, header information in the presently 45 ^is instance of the MOSAF object In addition the method 

preferred embodiment includes the name of the person valldates the Me nam ^ ^ aratcs * c filcaan \ e ^ m ** m 

posting the message, the subject of the message, and the date P ath ***** **«™* filc s !f aild cr u eate K S date/UmC data j 

and time the message was posted. Once header information or^ns the file and de ermmes if the file has been compressed 

has been entered at state 102 the message section is selected using PKZIP (by looking at whether the first two bytes of file 

at state 104 and an inquiry is made at decision state 106 50 contam the characters PK ) If the file has not already been 

whether to insert text into the message section. If the user compressed it is compressed into a temporary file the new 

wishes to add text into the message section then it is inserted fil f e size 15 determined, and the method writes the above file 

at a state 108. Normally, a user will insert some text which ^formation to the object storage. 

makes up a part of the message being posted to a desired STDMETHOD(SetFileld) (THIS_DWORD,WORD, 

group. The process 68 then inquires whether a file exists to 55 DWORD,DWORD) PURE; 

insert into the message section at a decision state 110. This method is used to set the file ID of any attached files. 

However, if there is no text to insert into the message at The file ID is required to download a file. Because of the 

decision 106, the process 68 moves directly to inquire structure of the BBS server system, the file ID is not known 

whether a file is to be inserted at decision 110. by the client until the message is downloaded to the client 

If a decision is made to attach a file then the file is 60 machine. The file ID is derived from the message ID and the 

identified at a state 112 by the user. In practice, once a particular position of the file within the RichEdit control 

decision is made to attach a file the user chooses a button (available by license from Microsoft as part of the Win32 

labeled, for example ATTACH, which would thereafter open SDK). This will be explained in more detail below in 

a window requesting the identity of the file to be attached to reference to FIG. 7. Briefly, the ID of the first file in the 

the message. After the name of the file has been entered into 65 RichEdit control is the message ID+1, the second is message 

the new window the user closes the window by clicking an ID+2 and so on. Thus, if the message ID was 1111, the first 

"OK" button, for example. * file ID would be 1112. 
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STDMETHOD(GetSizeOfFile) (THIS_LPDWORD) 
PURE; 

This method is used by the BBS client to retrieve the size 
of the file before adding it to the message to be sent. 
STDMETHOD(GetFileDataPtr) (THIS_JLPVOID*) PURE; 

This method is used by the BBS client to retrieve a pointer 
to the file data for adding to the message to be sent. 
STDMETHOD(SetFileRemotelnfo) (THIS_FILETIME*, 
DWORD,DWORD,BOOL) PURE; 

This method is used by the BBS client to set the price and 
the number of accesses for the file. Normally, this method is 
used on read. 

STDMETHOD(GetFileName) (THIS_LPSTR,int) PURE; 

This method is used by the BBS client to retrieve the 
original filename of the attached file. A list of attached 
filenames is generated for the BBS Save As dialog. 
STDMETHOD (QueueFileForDownload) (THIS_HWND, 
LPSTR, BOOL) PURE; 

This method is used by the BBS client to download an 
attached file through the File Transfer Manager (FTM) when 
a user has selected one or more attached files and clicks OK 
from the Save As dialog. 

STDMETHOD(GetFileCbmpType) (THIS_LPINT) PURE; 

This method is used by the BBS client to determine the 
file compression routine that was used to compress the 
attached file. These values can be NONE, PKZIP, or MSN 
INTERNAL. 

The MOSAF object also supports three verbs: Open, 
Download and Properties where Properties is the default 
verb (i.e. used on double click). These verbs are defined 
below: 
OPEN: 

The open verb method first checks to see if there is any 
application associated with the attached file. The file exten- 
sion is compared with the file extensions listed under 
HKEY_CLASSES_J*OOT in the Object Linking and 
Embedding registry. If no associated application is found an 
error message is displayed telling the user this fact. If an 
associated application is found, and the state of the MOSAF 
object is UNSENT then the file is opened with the associated 
application (for example, Microsoft Word). If the state of the 
MOSAF object is REMOTE, then the file is first down- 
loaded and then opened with the associated application. 
DOWNLOAD: 

The download verb method first checks the state of the 
MOSAF object. If the state is UNSENT then an error 
message is displayed notifying the user that the file cannot 
be downloaded because it has not been sent. If the state is 
REMOTE then it simply calls the QueueFileForDownload( 
) method and initiates a file download. 
PROPERTIES: 

The properties verb displays the properties of the attached 
file and has two buttons, "Download and Open" and "Down- 
load*'. The first button maps to the OPEN verb and the 
second button maps to the DOWNLOAD verb. 

The MOSAF object renders the file name and icon as a 
standard Windows Enhanced Metafile. This metafile is 
obtained using the OLE function GetIconOfFile( ). 

Once the file object has been created at a state 114 the 
name of the source file is retrieved into the object at a state 
116. In this manner, the file object is now linked to the 
source file by reference to its path and name. After the source 
file information has been retrieved at state 116 a temporary 
file is created at a state 118 and the source file is copied and 
compressed into the temporary file at a state 120. 

Thus, a compressed copy of the original source file is now 
stored in a temporary file on the user's computer. The 
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compression algorithm used to compress the source file into 
the temporary file is known as the DIAMOND compression 
system and is based on algorithms available within the 
Microsoft Corporation. However, it should be realized that 

5 many different types of file compression systems are avail- 
able and could be used to compress the source file without 
departing from the present invention. Further, compression 
is not a necessary aspect of the present invention. 

The source file is compressed into a temporary file at this 

to state so that it may be uploaded to the network more ' 
efficiently during the posting process. This process will be 
explained in more detail in reference to FIG. 4. Once the 
temporary file contains the compressed source file at state 
120, the temporary file information is retrieved from the 

15 temporary at a state 122. 

After this temporary file information is known, it is 
written to the file objects storage at a state 124 and the file 
object is inserted into the message section at a state 126. It 
should be noted that the BBS system uses an OLE registry 

20 to match the attached files extension with the correct icon. 
For example, a file that has an extension ".DOC will 
receive an icon indicative of the Microsoft Word word 
processing application. The OLE registry is part of OLE 
version 2.0. 

25 Once the file object is inserted into the message section of 
the message at state 126, the process 68 returns to inquire at 
decision state 110 whether to insert another file or not. If a 
decision is made to not insert a file at decision state 110, then 
the process 68 inquires whether the user is done or not at a 

30 decision state 128. If the user is not done, then the process 
68 returns to state 102 wherein header information can be 
entered. However, if the user is done at decision state 128 
then the process ends at an end state 130. 
Posting a Message 

35 The process 70 of posting a message as shown in FIG. 2 
is illustrated more completely in reference to FIG. 4. The 
posting process 70 begins at a start state 150 and moves to 
a state 152 where a message transfer file is created. The 
message transfer file is the data structure that is used to 

40 transfer the message and any attached objects to the network 
within the host data center 10. In this instance, the publicly 
accessible location is within the BBS server 26. The data 
structure of the message transfer file will be discussed in 
more detail below in reference to FIG. 5. 

45 Once the message transfer file has been created, the 
header information from the message is placed within the 
message transfer file at a state 154. As discussed previously, ' 
header information includes the subject of the message, the 
date and time the message was posted, and the name of the 

50 person posting the message. 

Once the header information has been placed within the 
message transfer file at state 154, the posting process 70 
adds the body of the message to the transfer file at a state 
156. As discussed above, the body section of the message is 

55 composed using a rich edit control which has the ability to 
output its data as a rich text format (RTF) stream. The RTF 
standard allows text and graphics, including font styles, 
emphasis, spacing and other features of the data within the 
control to be output in a standard form that retains all of the 

60 formatting commands. Thus, the data that is output in a rich 
text format can be recreated to include all of the appropriate 
graphics, objects and font styles. 

After the header information has been placed within the 
message transfer file, the rich edit control sends a rich text 

65 format stream to the message transfer file using Messaging 
Application Programming Interface (MAPI) compression 
techniques. Compression is provided at this stage because 
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the RTF stream contains many internal codes that represent to divide the file into the header and compressed RTF, and 

font descriptions, font changes, tab settings, etc. The MAPI finally all the appended files. 

compression is used to reduce the size of the RTF stream so At state 172 the header and message body section of the 

that file transfers will be more efficient. While MAPI com- message transfer file are stored to the BBS server. After the 

pression is used in the preferred embodiment of the 5 header and message body sections 220, 222, respectively 

invention, other similar compression algorithms could also have been stored, a query is made whether any appended 

provide similar advantages. Furthermore, the present inven- files exist at a decision state 173. If some appended files 

tion can be implemented without any compression of the exist, the first appended file is saved to the BBS server 26 at 

message. a state 174. As discussed above, the system saves the binary 

If objects have been placed within the body section of the 10 size of each appended file so that they can be extracted from 

message then the rich edit control interacts with those the message transfer file intact. 

objects and gathers data from them. The data gathered from After the appended file is saved to the server at a state 176, 

the objects is placed within the rich text format stream that a query is made at a decision state 178 whether more 

is output to the message transfer file. The process of con- appended files exist. If more appended files exist at decision 

verting data from objects from a rich edit control into a rich 15 state 178, then the next file is retrieved at a state 180 and the 

text format stream can be understood more clearly with process 70 loops back to save the next file to the server at 

reference to Inside OLE 2 by Kraig Brocksschmidt state 176. If no more files exist at decision state 178 then the 

(Microsoft Press). The command EM_Streamout is used posting process 70 ends at an end state 182. If no appended 

from the OLE 2 command set to output rich text format from files exist at decision state 173, the process 70 terminates at 

a RichEdit control. 20 end state 182. 

Once the message body has been converted to a rich text FIG. 5 shows details of the data structures "involved in 

format and placed within the message transfer file at state posting a message from a client 14 to the BBS server 26. As 

156, an inquiry is made whether any objects which reference shown, a message 200 has a header section 202 and a body 

temporary files exist at a decision state 158. As discussed section 204. The header section 202 includes information 

above in reference to FIG. 3, a temporary file is created 25 concerning which group will receive the message, who the 

when a file is attached to a particular message. The tempo- message is from and the subject of the message. The body 

rary file is a compressed version of the source file located on section 204 includes some text and a series of icons 206a, 

the user's local computer system. 206b, and 206c. The icons 206«, 2066, and 206c reference 

If a determination is made at decision state 158 that temporary files 208a, 2086, and 208c, respectively, 

temporary files do exist then the first temporary file is 30 As part of the posting process a transfer file 210 is created 

retrieved at a state 160. Once the temporary file has been as discussed above. Once the transfer file 210 has been 

retrieved at state 160 its binary size is calculated at a state created on the client system 14, the header information text 

162 so that its boundaries within the message transfer file corresponding to the header information is added into the 

can be determined. The BBS server 26 within the host data transfer file 210. The compressed rich text format stream 

center 10 can then use these binary size calculations to 35 that is output from the body section 204 of the message 200 

extract each attached file from within the message transfer follows the header information. As the rich text format 

file. This process will be explained more completely below stream is being output to the transfer file 210 a MAPI 

in reference to FIG. 7. compression technique is used to reduce the size of this data 

Once the binary size of the attached file is calculated at stream. Once the compressed rich text format has been 

state 162, the temporary file is appended to the end of the 40 stored within the transfer file 210, each of the temporary files 

transfer file at a state 164. If more temporary files are 208a,208l>, and 208c are added to the end of the transfer file, 

determined to exist at a decision state 166, then the next BBS messages begin with a RFC-850 & RFC-1036 

temporary file is retrieved at a state 168 and a process begins compliant header (with the exception that we terminate each 

again to calculate its binary size at state 162. fine with a carriage return rather than a carriage return and 

However, if no temporary files exist at decision state 166, 45 line feed) followed by a blank line and then the message 

or at decision 158, the posting process 70 begins uploading body. The format of the message body depends on the value 

the transfer file 210 (from FIG. 5) to the BBS server at a state of "X-MOS-Format" header field. Possible values are 

170. Uploading the transfer file to the BBS server 26 "TEXT", "RTF" and "RTF_COMP\ 

normally involves sending the file from a user* s computer 14 "RTF_COMF' is the RTF stream from the RichEdit 

through the wide area network 18 and the gateway 12 to the 50 control that has been compressed using the RTF compres- 

Bulletin Board Server 26. sion supplied by MAPI. WrapRTFCompressedStream is 

Protocols for sending files from an end user to a computer documented in the Windows 32 bit Software Developer's 

network are well-known within the art and can include Kit (Win32 SDK) available by license from Microsoft, 

protocols such as ZMODEM, YMODEM, or XMODEM. Messages with attached files are always "IRTF_COMP" 

After the transfer file 210 has been uploaded to the BBS 55 formatted. The OLE IStorage for the MOS Attached File 

server 26 at state 170 the message transfer file is parsed into (MOSAF) object is encoded in the RTF stream by the 

the message section 220 and the file sections 222 (from FIG. RichEdit control. Each attached file is compressed as it is 

5). converted into a temporary file and added to the end of the 

As part of state 170, the client 14 sends the size of the message in the order they appear in the RichEdit control, 

header and compressed RTF message and the binary size of 60 Thus, the message as it is sent to the server has the following 

each compressed, appended file to the BBS server 26. As this format: 

data is retrieved by the BBS server, it is placed into a header 

temporary file, along with the incoming message transfer blank line 

file. Thus, the BBS server temporary file contains the file message body 

from the client, plus the size of each appended file and the 65 file 1 

size of the header and compressed RTF stream. After the file2 
upload is complete, the server uses the file size information 
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file n 

The size of the header and body plus the size of each file 
is sent to the server with the message as discussed above. 
The server then creates one file to hold the header and body 
and creates a file for each attached file. After all of the 
compressed temporary files have been appended to the end 
of the transfer file 210 it is transmitted via well known 
means to the BBS server 26 within the host data center 10. 

Once the transfer file 210 has been sent to the BBS server 
26, it is parsed into the message section and file sections. 
The message section 220 includes the header portion from 
the original message and the compressed rich text format 
stream from the body section of the original message. In 
addition, each of the compressed files are removed from the 
transfer file 210 and stored in their own IStorages where a 
linkage is maintained within the compressed rich text format 
section of the message to the designation of each associated 
compressed file. It should be noted that in this system the file 
data is stored separately from the message IStorage so that 
the message section 220 can be sent to the client separately 
from the attached files. Although the message transfer file is 
a single data storage that is used for transporting messages 
and files from the client to the network, the files and message 
body are actually saved in separate storage locations or files 
once they reach the BBS server 26. 

For example, an uploaded file might be 1000 bytes long 
with a 250 byte header and body section, a 600 byte first 
appended file and a 150 byte second appended file. The 
server would then copy the first 250 bytes into the file used 
to store the header and body. The next 600 bytes would be 
copied into the file storing the first appended file while the 
remaining 150 bytes would be copied into the file storing the 
second appended file. As discussed above, the server is 
notified of each file size as the message transfer file is 
uploaded from the client to the BBS server. 

The server uses a numerical ID system to store appended 
files from the message transfer file. The numerical ID is 
assigned by the server when the upload is completed and 
functions by assigning consecutive ID numbers to each 
appended file. Thus, in the example above, if the header and 
body is assigned ID 4762, the first appended file would be 
assigned ID 4763, and the second appended file would have 
ID 4764. On the BBS server, the files containing this data are 
assigned names that are derived from the ID. In the simple 
case, the file name could be just the ID, for example a file 
called 4762. The file name is derived or generated from the 
ID, and thus always unique. 

When the BBS client is initiated, the server supplies a list 
of messages in the current folder. This list includes the 
subject of the message, the author, and, for each message, 
the ID of the message on the server. This is the mechanism 
used by the client for requesting a particular message. The 
client transmits a request to open a message having a 
particular ID number. 
Downloading Files 

Referring now to FIG. 6, the process of reading messages 
and downloading files 59 (FIG. 2) is illustrated in more 
detail. The process 59 begins at a start state 250 and moves 
to state 252 wherein the BBS server 26 sends the message 
220 (FIG. 5) to the user's (client) computer 14. Once the 
client computer has received the header and compressed rich 
text format stream from the BBS server 26 it is converted 
back into a readable message format as illustrated in mes- 
sage 200 (FIG. 5). The command 
WrapComressedRTFStream() is first used to decompress the 
RTF stream and then EM_STREAMIN is run to insert the 
RTF data into the richedit control of the message body 204. 
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Once the header and compressed RTF data have been sent to 
the client computer the client software converts and displays 
the message at a state 254. 

Once the software has been displayed to the user an 

5 inquiry is made at a decision state 256 whether or not to 
download any files referenced by the objects included within 
the body section 204 of the message 200. It should be noted 
that at this state only the objects have been downloaded to 
the client computer while the compressed files remain 

1Q located on the BBS server. This differs from many prior 
bulletin board services wherein the entire file is downloaded 
to the client at this state. Because only the header section and 
compressed RTF data have been sent to the client it is much 
faster to read many messages and then select the desired file 
to be downloaded. 

15 If a determination is made at decision state 256 to 
download a file then the process 59 moves to a state 260 
wherein the user selects an object within the message. 
Selection of the object can be made by, for instance, double 
clicking on the icon to indicate to the process 59 that the 

20 particular file associated with that object is to be down- 
loaded. 

Once the object has been selected, a download window 
appears which provides information about the file to be 
downloaded. This information would include, for example, 

25 the size of the file, the title of the file, the approximate 
download time, and perhaps the price of downloading the 
file to the client computer. The ability for the user to see the 
size of the file and the approximate download time while 
within the message window provides an advantage over 

30 prior systems which require the user to exit the message 
window to download a particular file. At this point, the user 
can decide to cancel the file download or to proceed with 
retrieving the file. It should be noted that this differs from 
Email systems wherein double-clicking opens the file asso- 

35 ciated with the object, but does not open a download 
window. 

As stated above, a price can be associated with the 
selected file. This ability to set prices for uploaded software 
could be used as a method for distributing shareware to the 

40 public for a reasonable fee. Once a user has downloaded a 
file which has an associated price, the users account is 
charged the amount owed for that particular file. The owner 
of the host data center 10 can thereafter pay the vendor that 
originally uploaded the file and attain a commission as a 

45 service fee. 

For example, a particular vendor as shown in FIG. 1 could 
upload a shareware utility to the host data center 10 which 
had an associated price of ten dollars. If a client decides to 
download this file, then the client's account would be 

50 charged ten dollars to be collected by the owner of the host 
data center 10. From this ten dollars, the owner of the host 
data center might pay the vendor eight dollars and retain two 
dollars for a service fee. This system provides a very simple 
and direct method of distributing software from vendors and 

55 users while providing benefits for all parties. 

The vendor responsible for uploading the software ben- 
efits by having its programs available to a wide range of 
individuals at a very low cost to the vendor. The owner of the 
host data center has an advantage in retaining service fees 

60 and commissions for processing payments while incurring 
almost no overhead for distributing the software. In addition, 
the client also benefits by not having to go to a computer 
store to purchase software. The software can be downloaded 
directly to the client's computer and thereafter automatically 

65 installed. This would be especially advantageous for clients 
that need software when retailing stores are closed or in a 
very time dependent manner. 
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If the client decides to download the selected file once the 
download window has opened, then a button marked "down- 
load" is chosen to initiate the file transfer from the BBS 
server 26 to the client computer. After the client has selected 
the download button, the file identification number stored 
within the MOSAF object is sent to the client file transfer 
manager 300 (FIG. 7) as indicated at a state 262 of FIG. 6. 
Once the client file transfer manager (FTM) 300 has 
received the file identification number at state 262, the client 
FTM sends the id number to the file transfer manager on the 
BBS server at a state 264. The file transfer manager server 
then accesses the host data center through their local net- 
work to request the file having the specified id number at a 
state 266. The BBS server then sends the requested file to the 
FTM server 24 which queues it for transfer across the wide 
area network to the client at a state 268. After the file has 
been queued at the file transfer manager server it is sent to 
the client at a state 270. 

Once the file has been sent to the client at state 270 the 
client side file transfer manager writes the retrieved file to 
the local hard disk for storage at a state 272. As discussed 
above, the file is in a compressed state and must be decom- 
pressed before being ready to use by the client. Therefore, 
the client file transfer manager copies and decompresses the 
file to a destination file in a download folder at a state 274. 
At this state, the file has now been decompressed and is 
ready to be used by the client. The process 59 of download- 
ing the file then terminates at an end state 276. The data 
structures used during this file transfer from the BBS server 
to the client are explained in more detail in reference to FIG. 
7. 

The data structures used to retrieve a message are shown 
in reference to FIG. 7. A BBS server 26 includes a message 
220 and a number of compressed files 222. In addition, the 
BBS server includes a second grouping of messages (group 
2) and their associated compressed files. As shown, the 
client 14 has viewed a message 200 which includes objects 
206a, 206b, 206c. By selecting icon 206b the user can 
initiate a download as explained in reference to FIG. 6 of file 
2 from group 1 of the BBS server 26. Once the client has 
read message 200 and selected icon 2065 the file ID that is 
associated with icon 2066 is sent via the client file transfer 
manager to the file transfer manager server which requests 
and queues file 222b. 

The compressed file 2226 is then queued to the file 
transfer manager server 24 and transmitted to the client file 
transfer manager 300. After the client file transfer manager 
300 has received the compressed file 2226 it is decom- 
pressed and stored to the client's computer in file 2086. 
Thus, the user can individually select particular files that are 
represented by objects from within a BBS message without 
having to necessarily download every attached file. In 
addition, time saving techniques such as file compression 
are used to ensure that the process of posting and retrieving 
messages is as efficient as possible, 

V. CONCLUSION 

The present invention provides several advantages over 
prior bulletin board systems, as discussed above. These 
advantages include the convenience of being able to include 
objects representative of files within the BBS message body. 
Because the actual message does not include any attached 
data files, throughput of the system of the present invention 
is very high. A client can browse through many messages 
without having to spend valuable on-line time waiting for 
unwanted files to be downloaded. 

The present invention can also include file compression 
techniques that are transparent to the user within the file 
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upload/download process. Transparent file compression 
alleviates the need for users to compress their files prior to 
uploading them to a BBS server. Other currently available 
systems force the user to first compress any files that are to 
5 be uploaded to the publicly accessible , location on a com- 
puter network. 

Although the invention has been described with reference 
to specific embodiments, the description is intended to be 
illustrative of the invention and is not intended to be 
10 limiting. Various modifications and applications may occur 
to those skilled in the art without departing from the true 
spirit of the invention as defined in the appended claims. 

We claim: 

1. In a computer network comprising a first client 
15 computer, a second client computer, and a publicly acces- 
sible bulletin board server, a method for posting a message 
and a file to and downloading the file from the bulletin board 
server, the method comprising the steps of: 

creating in the first client computer the message to be 
20 posted and inserting a file object representative of the 
file in the message; 
requesting the first computer to post the message to the 
bulletin board server, and in response, the first client 
computer recognizing the file object inserted in the 
25 message and the first client computer posting the first 
message to the bulletin board server and automatically 
uploading the file to the bulletin board server; 
displaying the message and a representation of the file 
object on a display of the second client computer; and 
30 downloading the file from the bulletin board server to the 
second client computer. 

2. The method of claim 1 wherein the downloading step 
comprises the steps of: viewing file information stored in the 
file object; and selectively transferring the file from the 

35 bulletin board server to the second client computer based on 
the file information. 

3. The method of claim 1, wherein the bulletin board 
server comprises a plurality of networked computers. 

4. The method of claim 3, wherein the posting step 
40 includes the steps of: transmitting the message and the file 

in a single information stream; and storing the message and 
the file on different computers within the plurality of net- 
worked computers. 

5. The method of claim 1, further comprising the step of 
45 automatically compressing the file in response to inserting 

the file object in the message. 

6. The method of claim 1, further comprising the step of 
automatically decompressing the file in response to the 
downloading step after the file is stored on the second client 

50 computer. 

7. The method of claim 1, wherein the message comprises 
a rich text format. 

8. The method of claim 1, wherein the message is part of 
a message thread. 

55 9. The method of claim 1, wherein the representation of 
the file object is an icon, and a third client computer input 
in the downloading step includes selecting the icon; and the 
downloading step further includes displaying object infor- 
mation relating to the file in response to the selecting of the 

60 icon on a display of the third client computer. 

10. The method of claim 9, wherein the selecting of the 
icon comprises the steps of: positioning a pointer on the 
icon; and actuating an input device. 

11. The method of claim 9, wherein the object information 
65 includes the size of the file. 

12. The method of claim 1, wherein the file object is an 
object-oriented object. 
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13. The method of claim 12, wherein the file object 
includes a data structure and routines to perform operations 
on a value stored the data structure. 

14. The method of claim 12, wherein the file object is a 
Microsoft On-Line System Attach File (MOSAF) object. 

15. The method of claim 1, wherein the file object 
includes a plurality of attributes, at least one of the plurality 
of attributes relating to the contents of the file. 

16. The method of claim 15, wherein the file object 
contains an attribute describing the compression method 
used to compress the file. 

17. The method of claim 16, further comprising the step 
of automatically decompressing the file in response to the 
downloading step after the file is stored on the second client 
computer if one of the attributes included in the file object 
indicates the file was previously compressed. 

18. The method of claim 15, wherein the file object 
contains an attribute describing the size of the file. 

19. The method of claim 15, wherein the plurality of 
attributes include a file ID, and the downloading step 
includes the steps of: retrieving the file ID from the file 
object; sending the file ID to the bulletin board server; 
accessing the file with the file ID on the bulletin board 
server; and sending the file from the bulletin board server to 
the second client computer. 

20. The method of claim 1, further comprising the steps 
of: 

evaluating the file, in response to inserting the file object 
in the message, to determine whether the file has or has 
not been previously compressed; and 

automatically compressing the file in response to the 
evaluating step determining the file has not been pre- 
viously compressed. 

21. The method of claim 1, wherein a third client com- 
puter input in the downloading of the file includes manipu- 
lation of the representation of the file object. 

22. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 
claim 1. 

23. In a computer network comprising a first client 
computer, a second client computer, and a publicly acces- 
sible bulletin board server, a method for posting a message 
and a file to and downloading the file from the bulletin board 
server, the method comprising the steps of: 

creating in the first client computer the message to be 
posted and inserting an object-oriented file object rep- 
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resentative of the file in the message, the file object 
having been instantiated from an object class; 

requesting the first computer to post the message and the 
file to the bulletin board server, and in response, the 
5 first client computer recognizing the object-oriented 
file object inserted in the message and the first client 
computer posting the first message to the bulletin board 
server and automatically uploading the file to the 
10 bulletin board server; 

displaying the message and a representation of the object- 
oriented file object on a display of the second client 
computer; and 

downloading the file from the bulletin board server to the 
15 second client computer in response to manipulation of 
the representation of the object-oriented file object. 

24. The method of claim 23, wherein the bulletin board 
server comprises a plurality of networked computers, and 
the message and the file are stored on different computers 
within the plurality of networked computers. 

25. The method of claim 23, further comprising the step 
of automatically compressing the file in response to inserting 
the object-oriented file object in the message. 

25 26. The method of claim 23, further comprising the step 
of automatically decompressing the file in response to the 
downloading step after the file is stored on the second client 
computer. 

27. The method of claim 23, wherein the message com- 
3Q prises a rich text format. 

28. The method of claim 23, wherein the message is part 
of a thread. 

29. The method of claim 23, wherein the file object 
includes a data structure and routines to perform operations 

35 on a value stored the data structure. 

30. The method of claim 23, wherein the file is automati- 
cally uploaded, using the object-oriented file object inserted 
in the message, to the bulletin board server in response to the 
posting of the message. 

^ 31. The method of claim 23, wherein the object-oriented 
file object contains a plurality of attributes, at least one of the 
plurality of attributes relating to the contents of the file. 

32. A computer-readable medium having computer- 
executable instructions for performing the steps recited in 

„ c claim 23. 

45 

* + * * * 
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